Apparatus and method for file size estimation over broadcast networks

ABSTRACT

The apparatus and method for estimating the size of content being received before the actual transmission of the data utilizes Electronic Service Guide (ESG) information. The ESG information assists a client device in obtaining file information before the file is actually transmitted by the source of the same. In this manner, the power supply of the user device can be managed more efficiently and provide the user with the ability to make storage determinations at their user device before expending the power resources necessary to obtain (i.e., download) and store a particular file of interest to the user without requiring any user intervention.

This application claims the benefit, under 35 U.S.C. §365 ofInternational Application PCT/US2007/025,810, filed 18 Dec. 2007, whichwas published in accordance with PCT Article 21(2) on 25 Jun. 2009, inEnglish.

BACKGROUND

1. Technical Field

The present invention relate to broadcast networks. More particularly,they relate to estimating file size before receiving the same.

2. Description of Related Art

Broadcast technologies, such as DVB-H, enable delivery of data tolow-power, portable client devices, which in turn enables content ondemand services. In such services, content is continually received at aclient and may be consumed by the end user immediately or consumed at alater time. In some cases, the amount of content that is stored islimited by the storage capacity of the client. When a service providesfrequent content updates, it is desirable to enable quick storage andreplacement of received data. In such services estimating the size ofcontent being received before the actual transmission of the data can behelpful in replacing already stored content or deciding what contentwill be stored in the future.

SUMMARY

According to an aspect of the present principles, the method for filesize estimation over a communication channel in a broadcast networkincludes estimating file size using broadcast schedule informationbefore actually receiving the file, and determining whether or not toreceive and store the file before downloading the same to a clientdevice automatically and/or without requiring user intervention. Thisdetermination is based on user preferences stored in a user profile onthe client device. The method can further include determining thebandwidth of the communication channel.

The file size estimation can be determined by deriving start and endtimes of the file from the broadcast schedule. In anotherimplementation, the file size estimation uses electronic service guide(ESG) information relating to the file from a service provider.

The bandwidth determinations can be performed by estimation, or byobtaining previously known values for the bandwidth of the communicationchannel.

According to another aspect of the present principles, the apparatusincludes a mobile client device having a memory contained therein andbeing configured to estimate a file size using broadcast scheduledinformation before actually receiving the file, and to automaticallydetermine whether or not to receive and store the file beforedownloading the same to the memory of the device automatically and/orwithout requiring user intervention.

The mobile client device is further configured to determine thebandwidth of a communication channel over which the file is to betransmitted to the mobile device.

A user profile stored in the memory of the client device enables theclient device to make the automatic determination without user requiringintervention.

According to another implementation of the present principles, theapparatus includes a mobile client device having a memory containedtherein. The memory includes a computer program product comprisingreadable program code embodied thereon for use in operating the mobileclient device. The program product includes program code for estimatinga file size using broadcast schedule information before actuallyreceiving the file, and program code for determining whether or not toreceive and store the file before downloading the same to the mobileclient device without user intervention. The client device furtherincludes program code for determining storage space limitations on theclient device using the estimated file size. This determination is madebased on stored preferences in the user profile stored in the memory ofthe client device.

Other aspects and features of the present principles will becomeapparent from the following detailed description considered inconjunction with the accompanying drawings. It is to be understood,however, that the drawings are designed solely for purposes ofillustration and not as a definition of the limits of the presentprinciples, for which reference should be made to the appended claims.It should be further understood that the drawings are not necessarilydrawn to scale and that, unless otherwise indicated, they are merelyintended to conceptually illustrate the structures and proceduresdescribed herein.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings wherein like reference numerals denote similarcomponents throughout the views:

FIG. 1 is block diagram of a bi-directional broadcast network scenarioaccording to known implementations;

FIG. 2 is a block diagram of a uni-directional broadcast networkaccording to known implementations;

FIG. 3 is diagrammatic representation of a clip and times at which theclip is to be broadcast;

FIG. 4 is diagrammatic representation of clip A to be broadcast andseveral clips stored in a client device;

FIG. 5 is flow diagram of the method for file size estimation accordingto an implementation of the present principles; and

FIG. 6a is block diagram of the method according to an implementation ofthe present principles;

FIG. 6b is a flow diagram of the method for file size estimationaccording to another implementation of the present principles.

DETAILED DESCRIPTION

There are known methods to estimate the instantaneous bandwidth of agiven channel. This is usually done on a bi-directional point-to-pointnetwork by measuring the amount of time it takes to acquire a knownquantity of data. FIG. 1 shows an example of a bi-directional point topoint network 100 where both the server 102 and client 106 are inbi-directional communication with each other via the network 104.

In most bi-directional client-server network architectures, a clientrequests a known quantity of data and records the start time and the endtime of data transmission through a series of network packets going backand forth between the server and the client, to estimate channelcapacity.

FIG. 2 shows an example of a uni-directional client/server architecture200 where the server 202 transmits data to one or more clients 204 a-c.

File Delivery can be performed using File Delivery over UnidirectionalTransport (FLUTE) protocol. FLUTE is a protocol for multicast filedelivery, and can be used to transmit data or content overuni-directional networks. A client can monitor the amount of dataflowing at any particular time and use this information to estimate thechannel capacity. In a constant capacity channel environment, thismeasurement could be done only once. In a variable channel, a besteffort of the channel capacity (i.e., bandwidth) can be maintained andconstantly updated.

A personalized broadcast video system provides a simple user interfacefor personalization, while efficiently using network bandwidth andminimizing receiver device battery usage. A user profile on a receiverdevice indicates the interests of the user. Individual clips to bebroadcast are associated with flexible metadata tags, such as keywords,sent in an Electronic Service Guide (ESG). The ESG contains informationabout television programs scheduled for broadcast, and typicallyincludes descriptive data, or metadata, about individual programs, suchas the name of the program, a synopsis, actors, director, etc., as wellas the scheduled time, date, duration and channel for broadcast.

The DVB-CBMS standard enables a service for broadcasting of multimediacontent files, such as compressed video or audio files, using DVB-H. TheDVB-H ESG provides a standardized ESG, which builds upon TV-Anytime orOn-demand programming. In the DVB-H ESG, individual pieces of contentare uniquely identified by the ContentID attribute of the contentfragment.

In cases where a service of personalized broadcast video system isprovided, content is continually broadcast and based on clientpreferences, content is received and stored. However, in such cases theclient tends to be switched on all the time and hence results ininefficient power usage. Power management would be more efficient if theclient only switched power on for reception of preferred content. Inorder to do this, however, the client has to decide which content can besaved based on local storage limitations, before the content is actuallybroadcast. According to an implementation of the present principles,this decision is established in the user profile preferences stored inthe client device so that no user intervention is required.

The DVB-H ESG advertises the use of a file size parameter in theAcquisition fragment in the ComponentCharacteristic type namedFileDownloadComponentCharacteristic under the Storage identifier.However, this only measures the file size as in megabytes and thisgranularity is not sufficient for providing advance notice of thecontent before actual broadcast.

As mentioned above, in unidirectional or broadcast networks there is nofeedback from a client. The client only receives data that is broadcast.In such scenarios, the client can estimate bandwidth by passivelymonitoring the data packets. In order to make estimates of the file sizeof the content that is going to be broadcast, an estimated value of thebandwidth of the channel is required. This can be done by using astatistical table of sampled bandwidth over time or any other method ofbandwidth estimation.

One example of estimating the bandwidth is by using the “b=” identifierspecified in the Session Description Protocol (SDP) file. The SDP filecontains a set of identifiers that associate with the acquisition ofcontent.

In another example, a client could timestamp the start of a packettransmission and after a period of time, derive how much data wasreceived. This would then help the client get an estimate of thebandwidth of the channel, where Bandwidth of the Channel=Number of bytesreceived/Time.

Another method of estimating bandwidth would be by using server provideddata to the client. For example by using the DVB-H ESG specification,the Storage identifier can be used as a rough estimate of the file sizeof a content file going to be broadcast. This rough estimate, along withthe start time and end time of broadcast from the already receivedschedule ESG fragment on the client device, can be used to estimate thebandwidth over an initial period of time. This is particularly useful insituations where the bandwidth of the channel is variable. The clientdevice can use this method to estimate the approximate bandwidth. Theclient can also use this method to calculate the error in its estimates.For example once the whole file has been downloaded the, actual size ofthe file is known and this can be used to recalculate the bandwidth andhence adjust the estimating parameters so that future estimates are moreaccurate.

A file download service may be defined as a service that providescontent for download in the form of files. These files are consumed atthe receiver application and presented to the user. Providers of thisservice need to be sensitive about client device power and storageneeds. Content is continually being broadcast and new content is storedon the client device while old ones are replaced. Replacing of oldcontent must be time, as well as power sensitive. Knowing the contentfile sizes in advance, a client device can make intelligent choices whenreplacing content on the device and at the same time make betterreception power management.

Once the bandwidth has been estimated the size of content to bebroadcast can be estimated.

Referring to FIGS. 3 and 4, consider a scenario where Clip A is going tobe broadcast at some time in the near future T1 and a client device 400contains stored file content Clips B, C and D in an memory area 402 ofthe client device. The broadcast time of Clip A is available to theclient by parsing the schedule ESG information it received from anearlier received transmission. The receiver (client device 400) has tomake a decision on whether or not to store Clip A. For purposes of thisexample, we assume the Clips B, C and D together take up a goodpercentage of the storage space on the device. The memory area 402 inthis example can be any type of known memory for storing content, and orprogramming information relating to the operation of the client device.In one implementation, the memory 402 contains the programming toimplement the methods and processes of the present principles disclosedherein.

The client device 400 uses the size of Clip A to make a decision whetherto store the clip. Using the estimated file size of Clip A, the clientcan make the decision in advance to either store or not store Clip A.For example without knowing the actual size of Clip A the client devicewould switch on at time T₁ and receive whole of Clip A. After completionof the file download (at time T₂), the file size of the clip is known.Based on this file size and other characteristics of the Clip A (e.g.keywords etc.), the client device can either store Clip A and replacesome existing content (Clip B, C and D) or discard Clip A. DiscardingClip A after having used the power to receive it, is wasteful in termsof power usage and hence reduces battery life.

Using the estimated file size of Clip A, the client device can make thedecision in advance to either store or not store Clip A. The device doesnot have to be switched on during the broadcast of Clip A if it decidesit doesn't need to store the clip, thereby reducing the power usage ofthe device by shutting off its reception components for that period.

Referring to FIG. 5, there is shown the method 500 where the receptionmodule (or client device) needs to be switched on regardless of whetherthe content was going to be stored or not. This is primarily due to thefact that the reception module 504 is started immediately after the ESGschedule is received 502. The content is received (506), and adetermination is made (508) whether the receiving of the content hasended. When the content is fully received, the downloaded size iscalculated 510, and the client device decides whether to store thecontent (512). If no, the received content is deleted (514) and thedevice returns to the receive schedule state. If yes, the receivedcontent is stored (516) and the device returns to the receive schedulestate. As mentioned above, this method requires the client or userdevice to be powered on and in reception mode at all times, and mayresult in an inefficient use of battery power, especially when the userdetermines to delete the received content, after complete reception.

FIG. 6a shows the method 600 according to an implementation of thepresent principles, where power usage at the client device is moreefficiently managed. Initially, the bandwidth of the communicationchannel is determined (602). As mentioned above, this determination canbe either an actual, known BW, or can be estimated using any suitableknown method for estimating the bandwidth of the channel. Once thebandwidth is known, the file (content) size can be estimated (604) usingthe previously received ESG information. When the file size has beendetermined, or estimated, the smart client device can determine (606)whether or not to download (store) the file (content) at the clientdevice without requiring the user's intervention. This determination ismade base on the user preferences previously established by the user inthe user profile stored in the memory of the client device.

FIG. 6b shows a more detailed block diagram of steps 604 and 606 of FIG.6a . Initially the schedule ESG is received 608. The received schedulelist is iterated over or reviewed for new future content broadcasts(610). The file size is then calculated (or estimated) from the scheduleinformation using the broadcast start and stop times (612). With thisinformation, the client device can be presented with the decision tostore, or not store the content (606). If the client device says “yes”,then the reception module is powered on, and reception of the newcontent is started (614). The client device starts receiving the content616, and once all the content is received (618), the content is stored620 and the process returns to the beginning. The client device willautomatically power down upon completion of the process. Generallyspeaking, the client device will power down if the device is not active.If the client device is in an active state, it will power down itsreceiving hardware components.

In accordance with one aspect of the present principles, the steps incalculating the file size over a varying or constant bandwidth channelare: From ESG:Duration of Broadcast=EndBroadcastTime−StartBroadcastTime.File Size=Bandwidth of Channel*Duration of Broadcast.

It is to be understood that the present principles may be implemented invarious forms of hardware, software, firmware, special purposeprocessors, or a combination thereof. Preferably, the present principlesmay be implemented as a combination of hardware and software. Moreover,the software is preferably implemented as an application programtangibly embodied on a program storage device. The application programmay be uploaded to, and executed by, a machine comprising any suitablearchitecture. Preferably, the machine is implemented on a computerplatform having hardware such as one or more central processing units(CPU), a random access memory (RAM), and input/output (I/O)interface(s). The computer platform also includes an operating systemand microinstruction code. The various processes and functions describedherein may either be part of the microinstruction code or part of theapplication program (or a combination thereof) that is executed via theoperating system. In addition, various other peripheral devices may beconnected to the computer platform such as an additional data storagedevice and a printing device.

It is to be further understood that, because some of the constituentsystem components and method steps depicted in the accompanying Figuresare preferably implemented in software, the actual connections betweenthe system components (or the process steps) may differ depending uponthe manner in which the present principles is programmed. Given theteachings herein, one of ordinary skill in the related art will be ableto contemplate these and similar implementations or configurations ofthe present principles.

The invention claimed is:
 1. A method comprising: receiving anelectronic service guide (ESG) data from a server, said ESG dataincluding a schedule list; determining a bandwidth of a communicationchannel between said server and a client, said client including areception module for storing a broadcast content from said server;iterating over said schedule list for a new broadcast content;estimating a size of said new content from said determined bandwidth andsaid schedule list, said schedule list including start and stop times ofsaid new content; determining whether to provide an operating power tosaid reception module for storing said new content at said client basedupon said estimated size of said new content and a preferencepre-provided by a user; and removing said operating power from saidreception module after said new content is stored when said operatingpower is provided to said reception module.
 2. The method of claim 1further comprising: determining a storage space limitation of saidclient based upon said estimated size of said new content, wherein saidpreference includes storing said new content by replacing an existingcontent on said client.
 3. The method of claim 1 further comprising:measuring an actual size of said new content after said new content isstored; adjusting a parameter for said bandwidth determination step inaccordance with said actual size of said new content.
 4. An apparatuscomprising: a client having a communication channel with a server via anetwork; a memory included in said client; a reception module includedin said client operative to store a broadcast content from said serverto said memory; said client operative to: receive an electronic serviceguide (ESG) data from said server, said ESG data including a schedulelist; determine a bandwidth of said communication channel between saidserver and said client; iterate over said schedule list for a newbroadcast content; estimate a size of said new content from saiddetermined bandwidth and said schedule list, said schedule listincluding start and stop times of said new content; determine whether toprovide an operating power to said reception module for storing said newcontent based upon said determined size of said new content and apreference pro-provided by a user; and remove said operating power fromsaid reception module after said new content is stored when saidoperating power is provided to said reception module.
 5. The apparatusof claim 4 wherein said client is operative to determine a storage spacelimitation of said memory based upon said estimated size of said newcontent, and said preference includes storing said new content byreplacing an existing content on said memory.
 6. The apparatus of claim4 wherein said client is operative to measure an actual size of said newcontent after said new content is stored, and said client is operativeto adjust a parameter for said bandwidth determination in accordancewith said actual size of said new content.